1. Field of the Invention
The present invention generally relates to the execution of programs (software codes) by an integrated microprocessor. The present invention more specifically relates to the control of the integrity of a program upon execution thereof, to check that the program has not been modified on purpose or incidentally since its installation. Such modifications may result from computer viruses or piracy attempts including, more specifically, of fault injections in the execution of programs.
2. Discussion of the Related Art
A so-called trap fault injection attack may include the introduction of a disturbance on the processor supply for a short time. Such an attack causes an unexpected jump in the program execution sequence. Most often, such an attack occurs when the program has looped back or has stopped on a blocking instruction after an authentication failure, for example, in an application where a processor must decide whether a specific operation is allowed (for example, in the case of credit cards, the authorization of a bank transaction after authentication of the user).
Another type of attack affecting the execution of a cryptography algorithm includes having the program counter jump to cause an unexpected jump in the execution sequence, even if the program has not stopped in a loop upon authentication. For example, for cryptography algorithms such as Digital Signature Algorithm (DSA), Rivest-Shamir-Adleman (RSA), Data Encryption Standard (DES), Advanced Encryption Standard (AES), the secret keys can be discovered by a piracy causing instruction jumps.
To protect the software code upon execution thereof, a periodic checking of this code is generally provided based on an authentication key stored in a memory or in the integrated circuit, for example, upon initial storage of the program or installation thereof.
For example, a signature (application of an encryption algorithm to at least a portion of the software code) is calculated upon installation or writing of the program. This signature is then stored in or outside of the integrated circuit executing the program. Then, upon execution of the software code, the operating system recalculates a signature based on the same algorithm as that having served to the generation of the initial signature. The current signature is then compared with the predetermined signature. A divergence between the two signatures means that the stored program has been modified and thus enables identifying a potential unwanted or incidental attack.
An example of such an integrity checking method is described in U.S. Pat. No. 5,442,645, which is incorporated herein by reference.
A disadvantage of known solutions is that in case of an updating of the software with a more recent version, it is then necessary to update the predetermined signature. Such an updating may be penalizing especially in case of a frequent updating of the system.
Further, program updatings more and more often occur via Internet-type communication networks, and it is not desirable to multiply signature calculations to be re-recorded in the integrated circuit on the user side.
Another disadvantage of conventional solutions is that the integrity checking is static, that is, at the beginning of the program, it is checked whether the signature is or not authorized. Accordingly, such a protection system is in practice inefficient in case of a fault injection during program execution.